測試人員不好找, 這是大家公認的事實. 一方面大家的要求都滿高的, 希望他能擅常找 bug, 要能懂環境和領域知識, 並且還要能寫自動化程式. 另一方面, 很多人不願意去當測試人員, 或者是去執行測試的工作. 外加薪水不到位, 那其他就一切免談.
撇開這一切不利的因素, 如果我們需要找一位好的測試人員, 那他應該有什麼特性:
• 具有工程背景知識
畢盡你是在資訊產品, 沒有工程背景真的不太合適.
• 基本程式開發能力
以前可能不需要, 現在幾乎都說要能寫程式.
不過, 如果只是寫測試程式, 去當測試自動化工程師, 老實說對找到 bug幫助不大, 但是老闆高興就好.
當然, 有些公司的薪水和公司狀況, 說要找寫程式的測試人員可能不容易, 讓不會寫程式, 但是有這邊其他項特性, 還是可以先考慮. 否則你就真的找不到人了.
• 系統層次的思考能力
他不能只看他手上測試的部分, 需要思考整體, 哪邊風險比較大, 因為畢盡你是無法有時間測完全部, 要利用全局觀去考量.
• 問題分析技巧
前面說過只會抓 bug 還不夠, 你還需要分析錯誤可能怎麼發生, 你能提供越多資訊, 開發人員和管理者會很感激你的.
• 對品質的熱忱
開發人員也可以把測試給做好, 不過他缺乏的是對品質的熱忱, 他們在乎的是技術的卓越. 所以你才需要有人從品質的思維出發, 寧可錯殺絕不放過, 不斷質疑一切, 這樣才能抓到問題.
• 喜愛找出背後運作原理
他必須要思考背後如何運作的, 不是開發人員跟他講什麼, 他就全盤接受, 要能進一步探索, 看看程式碼, 看看 log, 是否真的是那樣.
• 想讓系統失效
簡單說, 就是想辦法給系統死. 不能像開發人員那樣, 自己的系統像自己的小孩, 不捨得打, 這樣就找不到問題.
具備這些特性後, 我們才進一步來看, 哪些技能他需要具備
• 硬技能
軟體測試知識
受測產品相關領域的知識
受測產品所需技術
• 軟技能
溝通
同理心
分析和組織
調適
知識學習
主動積極
從這裡可以知道, 硬技能大家都知道是什麼, 也容易可以衡量. 但是對於軟技能方面, 不容易衡量. 但如前面所說的, 測試某種程度是找麻煩的工作, 要能讓對方聽得進去, 聽得懂, 溝通能力和同理心很重要. 並且為了讓對方聽得懂, 你必須要用對方的語言, 懂對方的知識, 所以學習開發相關知識是需要的.
那一個開發團隊中, 會有哪些測試的角色呢? 基本上有以下這幾類:
圖 30-1 常見的測試角色
• 測試經理
整理出高層次的計畫, 需要多少測試人員, 有哪些機器可以使用. 並且在執行過程, 追蹤測試進度, 根據執行結果調整計畫. 並且最後和相關利害關係人討論測試是否通過.
• 測試分析師
想辦法讓測試計畫中事情可以落地, 功能要怎麼測試, 要測試哪些場景. 測試環境要如何設計和安排. 當測試過程遇到技術性問題, 可以排解問題或是提出建議.
• 自動化測試人員
主要工作是撰寫測試程式, 提供相關的工具或是測試成員, 來執行測試, 輔助產生測試資料, 或是讓其他人測試時可以比較方便.
• 測試環境管理員
當測試環境很複雜, 需要有人管理, 進行環境的安裝, 還原, 和維護. 也需要週期性備份測試環境, 以及確保安全性.
• 測試執行人員
負責測試工作的執行. 有時候這裡是專職的測試人員, 也有些公司會請工讀生, PM 或是 UX 人員來幫忙.
一般公司不太可能每個角色都有, 但是測試的工作種類就是這麼多, 所以有些人就會同時兼很多角色, 負責不同種類的工作.
如果要找到很厲害的測人員, 這通常是件可遇不可求的事. 所以你大多只能先找基本盤不錯, 有熱忱願意學習的人先開始. 那接下來就是提升他們的能力. 那要如何提升軟體測試能力呢?
以下是之前一些個人經驗, 大家可以參考看看
• 了解客戶
• 多讀 bug 報告
• 多讀 程式碼
• 為找到 bug 感到驕傲
• 參與功能的設計
• 了解你要測試的功能
• 和別人合作測試你負責的功能
• 提供開發的能力
• 參與相關社群
• 學習你測試的軟體系統
• 和 RD, PM 培養良好關係
• 尋找導師和益友
• 持續自省
• 管理自己的時間
• 適當地自動化你的工作
• 參與 bug 檢視
• 持續學習新技能
簡單地說, 沒有所謂專門的時間去學習, 就不斷地在工作中的各個階段, 去精進自己的能力.
知道這些資訊後, 那接下來要怎麼找人, 基本上我會注意以下面向
• 最好團隊成員背景比較多元
bug 通常出現在你沒想到的地方, 如果太多相同背景, 可能思路會雷同, 如果有不同背景, 讓你在開立測試個案時, 可以想出不同角度的測法.
• 尋找有熱情和正直的人
找錯誤和糾正別人測試, 是一件不容易的事情, 很容易會讓人有挫折感. 因此, 要有超級熱情的人才能撐得下去.
另外, 他也需要對品質有堅持, 不會因為時間不足就放棄. 或者是管理者的權威, 就屈服他對品質的標準.
• 善用不同管道找人
以下我常使用的方式
a. 社群:
像是 Test Corner 之類.
b. 測試研討會:
目前台灣沒有這種研討會, 對岸不少, 如果在對岸有遇到台灣過去參加的, 千萬不要放過
c. 好的測試人員的人脈:
厲害的人通常會認識厲害的人. 所以提他們推薦也是很有用的
d. 在部落格上發佈測試人員有興趣的題材
用些議題在釣出相關厲害的人
e. 利用有挑戰的題目來招募
• 當場結對測試或是實機測試
• 慎選其他小組不要的人
有時候別的團隊會丟人給你, 有些是想轉測試. 有些可能是不適任的開發人員, 他們主管幫他找出路. 有的是 PM 想轉技術職, 因此從測試先開始. 不管是什麼原因, 自己不要因為人情壓力, 就降低標準.
測試可能的團隊結構
圖 30-2 只有開發的團隊結構
• 優點
各自專職, 各有專業
同一主管可以協調衝突
工作時間比較可以調配
• 缺點
因為時間壓力, 主管容易在意進度
開發和測試人員, 可能勾結或對立
測試人員無法約束開發人員
• 適用時機
專業分工的組織, 軟體公司居多
在意產品品質
公司願意投資測試
圖 30-3 開發和測試混合的團隊結構
• 優點
各自專職, 各有專業
同一主管可以協調衝突
工作時間比較可以調配
• 缺點
因為時間壓力, 主管容易在意進度
開發和測試人員, 可能勾結或對立
測試人員無法約束開發人員
• 適用時機
專業分工的組織, 軟體公司居多
在意產品品質
公司願意投資測試
圖 30-4 有獨立測試團隊的結構
• 優點
測試獨立自主
不用每個開發團隊都配置測試
測試有其權威性
• 缺點
測試可能對產品不熟
時程和資源不易搭配
容易讓開發不懂測試
• 適用時機
不太想投資太多在測試上面
非軟體公司居多
挖 突然發現是最後一篇文章了!
想說今天還會有第31天.
感覺後面可以寫得東西可以再跑一輪鐵人賽.
感謝你的支持. 這種連續寫的日子還是不要太常出現